前文 <專案管理的傳統方法：瀑布式開發> 中提到，瀑布式開發是一種由上至下的流程，一環扣一環，不可跳過中間任何步驟。這種「一步接一步」方式容易導致一些問題，例如利害關係人要等到最後階段才有機會看到成果，等到看到的時候，有可能才發現不符合客戶一開始的想像，這時候也來不及修正了。其他還有由於開發時程較長，開發好的功能，可能到了要交付的時候，經過這幾個月，市場已經產生了變化，而這個開發單位好不容易做出來的成品，此時已經不合時宜。

分析一下關鍵原因分別是：

(1) 客戶／關係人只參與前期的需求訪談，以及最後的驗收，中間沒有機會對話

(2) 瀑布的一個閉環運作時間太長，迭代的速度慢

敏捷開發（Agile）的出現，是為了解決這二個問題，它強調的是「對話」、「透明」，以及「迭代」。

敏捷價值觀

敏捷的核心精神，盡在其宣言之中，雖然它們只是描述敏捷價值觀的守則，原文中並沒有提到一定要怎麼做，我對於這些宣言的解讀如下給大家參考。

(1) 重視個人與互動甚於流程與工具：工具與流程可以使用團隊熟悉的即可，真正的重心應該要放在團隊之間的互動溝通，以及資訊透明同步。

(2) 重視可用的軟體甚於詳盡的文件：再多的規格描述，不如一個實際可用、可展示、可收集回饋的軟體成果，哪怕它還只是個 MVP 0.0.0.0.1。

(3) 重視與客戶合作甚於合約協商：想辦法與客戶、利害關係人創造出一種互信且雙贏的合作模式，而非甲方乙方彼此小心防範的關係。

(4) 重視回應變化甚於遵循計劃：遇到變化不消極裝死，勇敢正視變化、提出相對應的修正調整，而非死板地遵從原訂計畫。

敏捷 12 原則

敏捷宣言背後也有提到一些原則，條列如下：

1. 我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。
2. 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢。
3. 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
4. 業務人員與開發者必須在專案全程中天天一起工作。
5. 以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。
6. 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
7. 可用的軟體是最主要的進度量測方法。
8. 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。
9. 持續追求優越的技術與優良的設計，以強化敏捷性。
10. 精簡，或最大化未完成工作量之技藝，是不可或缺的。
11. 最佳的架構、需求與設計皆來自於能自我組織的團隊。
12. 團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。

這 12 個原則是不是有點多，其實靜下心來讀完，會發現所有原則，總結來說就是一件事：經營好團隊，交付出成果，提早創造價值。整理成一張圖來說明，相信大家就能夠明白。

同樣以製造汽車做為比喻，敏捷與瀑布的差別，大概會像是底下這二張圖：

現代專案管理趨勢已然祟尚敏捷，敏捷所重視的是三項重點：降低風險、盡早交付價值，以及持續改善。但敏捷（Agile）只點出了指導原則，並沒有明確地告訴我們該怎麼做到。為了能夠持續交付價值、獲取回饋與提高應變能力，我們還需要一個實際可運行的方法－ Scrum 框架。